Wstawki

Wstawka numer 118

Koszalin, 17. czerwca Roku Pańskiego 2021.

Apollo powstał w Apollu

Tak, to możliwe. Apollo był najpierw zwykłym edytorem tekstu zaczerpniętym z programu Dev-Pas. Kompilował się z pliku BAT (*.bat). Po dodaniu modułu uruchomienio­wego i prostego przycisku w menu Kompiluj, zaczął się sam kompilować. I tak powstał za­lążek, z którego krok po kroku, po każdej zmianie źródła otworzonego i wyedytowanego w Apollu, powstawał stale nowy Apollo. Można powiedzieć, że rósł jak kula śniegowa, albo lepiej jak żywa istota, rozbudowywany i stale ulepszany.

Są ludzie wiecznie niezadowoleni a szczególnie z osiągnięć innych. A gdyby tak, za­miast szukać dziury w całym i krytykować to, że czegoś nie ma, zauważyliby to, co jest. Tacy ludzie są jak wsiadający do samolotu, który narzeka, że mu tu okna otworzyć nie można, a w samochodzie może. Może i w karecie. A furą końską jak się jeździ z rozwiany­mi włosami. Jednakże chyba nie z takimi prędkościami i nie na takich wysokościach, jak zwykłe dziś samoloty pasażerskie, gdzie udusić się można bez powietrza, gdyby nie herme­tyzowana kabina.

Ale my zauważmy, że Apollo wyrzuca z siebie aplikacje o bardzo małych rozmia­rach. Są to w istocie aplikacyjki. Na rysunku widać takie maleństwo z Apolla do odwraca­nia zmiennych całkowitych w szesnastkowe i na odwrót oraz prawie identyczny programik z Delphi. Źródło procedur programu zostało zaimportowane z Apolla do Delphi. Program z Apolla ma 69 KB a delficki (czy delphicki) ma 382 KB. Nie powiemy, jaki jest plik lazarusowy odpowiedniej aplikacji - co niech sobie Czytelnik sam sprawdzi. A przecież Apollo używa (jako silnika) tego samego (a czasem ciut nowszego) kompilatora FPC co La­zarus. Nasze ma­leństwo z Apolla ma nawet o jeden komponent wizualny więcej niż jego delficki odpo­wiednik a mimo to rozmiary na dysku są prawie sześciokrotnie mniejsze. Taka aplika­cja szybciej się kompiluje, startuje, bo i nośnik (twardy dysk, pendrive… czy pendrajw) za­ładuje ją szybciej i skakania po RAM-ie jest mniej, czyli i chodzi szybciej. Czy to mało?

Na następnym rysunku są dwa identyczne funkcjonalnie programy Apolla (67 KB) i Delphi (377 KB). Oba podają wersję systemu Windows.

To, że Apollo nawyrzuca więcej plików dodatkowych, nic nie zmienia, gdyż prak­tycznie wszystkie te pliki (oprócz *.rc, *.h i *.ico) można usunąć z katalogu, po skończeniu pracy nad projektem, gdyż Apollo je odbuduje. Ma tylko jeden plik źródła więcej, zazwy­czaj nazywany GenForm, który zawiera klasę TApollo i funkcje eksportowe generujące pętlę karuzeli Windows WindowProc() i rejestrację klasy aplikacji WinRegister(). Dzięki temu plikowi programista wie, co aplikacja naprawdę robi. Czy to ciągle mało?

Są tacy, dla których mało to za mało? Zatem, dołóżmy im więcej. W Apollu jest na przykład funkcja HexToInt(). Ma nieco mylącą nazwę, bo w istocie zamienia wartości szes­nastkowe na zmienne naturalne a nie ogółem na całkowite, ale robi to sprawnie. Do­datkowo wartości wpisane w okienko do zamiany najpierw na zmienną szesnastkową, mogą być z wtrąceniami spoza cyfr a mimo to Apollo przekształci je prawidłowo w liczbę i zapisze w hex-ie (czy heksie). Jak kto woli. I to samo zrobi funkcja HexToInt(). Na przy­kład z formatu $00AF, czy #00AF, czy 00AF czy ostatecznie AF zamieni na prawidłową wartość liczby na­turalnej 175. To wyjątkowo plastyczna metoda. Nie zwraca błędów z byle powodu jak del­fickie czy lazarusowe funkcje.

Apollo ma sporo takich funkcji. Nie wszystkie są w pełni wypróbowane, mogą zwracać jakieś błędy. Jednakże obecnie Apollo to program w wersji Hiper Beta… o czym jest na stronie www.hendzel.pl i w samym Apollu. A sama aplikacyjka hexowa leży w kata­logu (choć większość nieza­dowolonych woli nazwę folder) Examples/HexToInt. Co widać na obrazku. Czyli dostarcza­na jest z Apollem jako przykład w postaci kodu źródłowego projektu wraz z wieloma inny­mi przykładami.

Apollo nie zapisuje domyślnie projektu ani żadnego pliku wraz z kompila­cją – czyli przed nią. Kompilator pobiera wartości do kompilacji zawsze z pliku źródła, za­tem łatwo się domyślić, że musi być zapisane źródło przed kompilacją, by uwidocznić wy­nik zmiany źródła. Czemu tego nie robi? Aby programiście weszło w krew, że swoją pracę trzeba zapisywać w trakcie pracy, by jej nie utracić. Automat rozleniwia. I czasami pracu­jąc klepie się kod, licząc na to, że guzik kompilacji załatwi wszystko i zapisze plik źródła. A tu bęc – i wyłączyli prąd, czy poszedł akumulator w UPS-ie czy laptopie. Ktoś, kto nigdy nie stracił wyników swojej pracy, nie wie, co to jest. Dlatego lepiej mieć odruch – jest coś ważnego wklepane, zapisuję plik. To jak używanie kierunkowskazu. „E, po co mam się wy­silać, kiedy pusto.” - i tak stale. Aż tu nagle pakuje się taki w duży ruch uliczny i znowu (tylko może trochę większe) bęc. Bo się przyzwyczaił, że mu środowisko samo zapisze plik źródła. Czy ktoś myśli, że to dużo pracy, dokleić zapis przed kompilacją? To dwadzieścia sekund pracy. Ale zły nawyk, to zły nawyk, a my chcemy mieć dobre nawyki.

Jest wiele takich miejsc w Apollu. I dzięki temu środowisko jest użyteczne i szybkie. Ma małą paletę komponentów, ale tu trzeba poczekać. Nie pali się. Najważniejsze są me­chanizmy pracy, analizy kodu i jakości kompilacji. I są pilniejsze potrzeby niż budowanie palet. Na paletach jedzie obecnie pół Polski, bo wygląda to tak, że nic innego nie umiemy, tylko zbijać palety i potem na nich wozić cudze towary. I to u obcych na placu. A to nie tylko nieamerykańskie, ale przede wszystkim niepolskie.

Z Bogiem.

Andrzej Marek Hendzel